I really don't see the issue with having no top level symbol.

Naming will always be a result of compromises.

If someone truly wishes to write dotless instead of dotless.i, then let them.

I think the change I would like instead is to change dotless.i and dotless.j to i.dotless and j.dotless instead. Especially because some symbols that we may want to add in the future are also variation of Latin letters that would benefit from this naming schema (e.g., F.inv for U+2132 Ⅎ, G.inv for U+2141 ⅁, L.inv for U+2142 ⅂, L.rev for U+2143 ⅃).

Of course as of now those would not be accessible in Typst math, but I think it may be sensible to allow the base identifier of a field access to be a single letter in math (the same way the identifier after the period can already be a single letter). @isuffix thoughts?

I think single letter identifiers would be a bad idea.

Something like

and therefore
$
 a = b + c.
$

would now presumably be a syntax error.

Your examples could (almost) equally well be inv.F, inv.G, inv.L, rev.L, with the added benefit that all such characters would be grouped.

Something like

and therefore
$
 a = b + c.
$

would now presumably be a syntax error.

Well, $ alpha + beta = gamma. $ is not a syntax error today, so I wouldn't think so.

Fair enough, but I still strongly dislike the idea.

Well, I strongly dislike having things that work like modifiers before the base symbol name. It's the opposite of consistent.

Well, I strongly dislike having things that work like modifiers before the base symbol name. It's the opposite of consistent.

It's impossible to achieve complete consistency. That's why I mentioned compromises above.

And even if you could achieve perfect consistency, that may not necessarily be the most usable option.

I also think single-letter identifiers are probably a bad idea and that i in math should be either a letter or a symbol binding, but not "both, it depends...".

@Enivex I can see that the current state can seem no big deal but is there a downside to the proposed change (other than breaking the code of someone that writes dotless instead of dotless.i)? It does seem conceptually more correct...

I also think single-letter identifiers are probably a bad idea and that i in math should be either a letter or a symbol binding, but not "both, it depends...".

A single letter can already be interpreted as an identifier, such as i in dotless.i. So it already depends on the context.

I could be open to allowing i.dotless to act like a field access on i. It seems like there are multiple reasonable uses and it makes some sense given the one-letter modifiers on other symbols like arrow.r. This would break the general rule that single letters don't act like identifiers, but that is a lexical rule, and adding a dot and another identifier does seem to create a new lexical context where a field access could be reasonably intended.

However, I am concerned about creating errors in expressions like i.x where x isn't a field of i. Currently Typst lets you be quite sloppy with dots and single characters, and I find it to be reasonably ergonomic that I don't have to consider errors for x.field or x.y. A common example where those might come up would be the forall and exists quantifiers, where $forall a.a=a$ would now error.

Another example would be the lambda calculus, where expressions like $lambda x. lambda y. x y$ are quite common, and if a user isn't careful with their spaces, either of x.lambda or y.x would start to produce an error with this change. I did a bunch of lambda calculus with Typst for some assignments in university, and (with some regular expressions) I can find over a dozen examples of me writing both the x.lambda and y.x forms, so this is a strong concern for me.

And while we could recognize x.lambda as not being a valid field access and render it as x . lambda at runtime, this would lead to asking whether pi.lambda might fallback to rendering as pi . lambda, which I find absurd, so I would not consider that option.

Overall, I agree that this could be a better interface for these characters, but I don't think allowing this syntax would be worth the ergonomic price in strictness around single characters and dots.

Thanks for the detailed answer.

Since I am the only one in favor of supporting i.dotless, I think the next best option is to use a submodule rather than a symbol. I agree with this:

I can see that the current state can seem no big deal but is there a downside to the proposed change (other than breaking the code of someone that writes dotless instead of dotless.i)? It does seem conceptually more correct...